Allow custom importers. #25
Conversation
|
Updated the PR to support custom importers which may return absolute import paths. |
|
@jgranstrom Any thoughts on this? |
|
@jgerigmeyer thank you for this, and sorry for the late reply. There should definitely be support for providing custom importers, so this is great. I will merge this and include it in a new release, however before that it would be great if you can amend the commit messages and change the message format to the convention used in all other commits and mentioned in the readme to keep it consistent and generate changelogs. There is some details on that process available. |
jgerigmeyer
force-pushed
the
custom-importer
branch
from
925faa1 to
fc919a0
Compare
|
@jgranstrom Rebased with new commit message. Let me know if that looks okay! |
|
@jgerigmeyer perfect, thank you! I’m currently a bit off the grid but will try to release this later today! |
|
I published this in version |
|
Thanks! |
Fixes #24.
If a user passes in a custom
importeroption, this PR now passes that option through tonode-sass. It also modifies the sass-extract specificimporterto preprocess the filepath through any custom importers first.node-sassaccepts both sync and async versions ofimporterfns, and also accepts an array of fns or a single fn. This PR supports (and tests) all of those cases.If the user, however, has an
importerfn which returns{ contents: <...> }(instead of{ file: <...> }), that is not supported. It will still pass through to node-sass (so the files can be compiled properly), but sass-extract won't be able to extract variables from those imports. I think those would be unusable by sass-extract in any case?